User-Centred Requirements Handbook |
User-centred design is an approach to interactive system development which focuses specifically on making systems usable and safe for their users. User-centred systems empower users and motivate them to learn and explore new system solutions. The benefits include increased productivity, enhanced quality of work, reductions in support and training costs and improved user health and safety. Although there is a substantial body of human factors and ergonomics knowledge about how such design processes can be organised and used effectively, much of this information is not yet widely applied.
Adopting a user-centred design process leads to more usable systems and products. It reduces the risk that the resulting system will under-deliver or fail.
User-centred design implies:
The process of user requirements specification described in this document is based upon these principles. In particular it is an iterative process based upon the design cycle presented in the user-centred design draft standard ISO 13407 (1997b) shown below:
FIGURE 1. THE USER-CENTRED DESIGN CYCLE
The main cost of achieving the benefits of user-centred design is that the manager's task initially appears more difficult. Project planning has to allow for iteration and for incorporating user feedback. More time will also be required for effective communication between design team participants and for reconciling potential conflicts and trade-offs. However, project managers will benefit from the additional creativity and ideas from an extended development team and skill base. Users will also feel a strong sense of ownership of the system that results. Above all, proper consideration of usage issues early on in the project will result in a better design and significant savings at later stages when changes are much more costly.
Requirements analysis is the first stage in the user-centred design process. Later stages are described in the INUSE Handbook of User Centred Design (Daly-Jones, Thomas and Bevan, 1997). The Handbook also describes the principles of user-centred design, based on the ISO 13407 standard (ISO, 1997b).
Requirements analysis is the process of determining what is required of a future system or product. This may be a computer-based system for a particular customer or a product to be launched onto the open market. This document uses the term 'system' to cover all classes of application including large scale computer-based systems, software packages and standalone electronic products.
Typically the process starts with a project proposal or project brief. This describes what is wanted from the proposed system in general terms. From this starting point, three kinds of requirement are developed:
All three of these sets of requirements must be carefully developed to ensure the success of the new system. Historically they may have been seen as separate, and the importance of user requirements is often overlooked. The three types of requirements should be developed logically in the order given above, and to achieve a successful design should be carried out as part of a common business framework. This guide is concerned with the capture and specification of user requirements and user functions, rather than organisation and business requirements or technical requirements. The complementary technical requirements will be of two types: specifications developed to meet the need of the user requirements, and constraints on how the user requirements can be achieved, related to the nature of available technology.
Traditional approaches to requirements engineering concentrate on identifying functional requirements and validating that the developed product meets these requirements. Other non-functional requirements (efficiency, reliability, usability, maintainability and portability), have had less importance. Yet from a user perspective, non-functional requirements may be critical to successful implementation of a new system.
RESPECT provides a broad framework for requirements engineering which makes meeting user needs to achieve quality in use the overall objective of the design process (see Bevan and Azuma 1997, Bevan 1997, Bevan 1998). Neither functionality nor usability (in the narrow sense of an easy to use interface) is given priority: they are subservient to the objectve of providing a system which enables the user to meet their goals in the real world. Depending on the context of use the user's goals may be business or personal objectives.
RESPECT emphasises the importance of obtaining a complete understanding of user needs, and validating the emerging requirements against potential real world scenarios of usage. Existing requirements engineering methods and tools can be used within this framework to document and trace the detailed requirements through the development process. The scenarios developed by RESPECT provide support for the definition of more detailed "use cases" used by some requirements engineering processes.
RESPECT methods will help prioritise requirements from a user perspective. RESPECT also introduces additional requirements of two types: detailed contextual requirements associated with scenarios of use, and high level quality in use goals (also called usability goals) for the users to be effective, efficient and satisfied when carrying out their tasks.
The RESPECT approach to user requirements forms part of a broader framework for user centred design, documented in the INUSE Handbook of User Centred Design. The INUSE handbook describes the methods which can be used to implement the design from a user-centred perspective.
Where a system is being developed for a small company or is for a few internal users at a large firm, the RESPECT method (described in Part B) can be used as a free standing method. However for larger projects, the method will need to work within the structure of an established software engineering procedure.
Most large software projects are developed using some version of the "Waterfall method". This assumes that a system is developed through a clearly defined series of steps or "Phases".
The steps are typically:
In its strictest version, the traditional approach states that each phase must be completed before the next phase can begin, and that the development team should not need to return to an earlier phase to redefine a system as it is being developed. However most software engineering specialists today realise that this approach is unrealistic and that for interactive system development, iterations in the process are needed.
Various modifications to the phases of the waterfall method and their interaction have been proposed. However software development environments still incorporate many steps of the method, partly for historical reasons and partly because the approach helps to define responsibilities and costs for various activities within a large software project. Thus the RESPECT method can supplement some of the stages of a waterfall environment.
The Waterfall method's initial "Requirements Analysis" phase describes the activity of defining the precise needs that the software must meet. These needs should be defined in terms of the users' needs, rather than how they will be met by the proposed system. However traditional software engineering tends to take an idealistic view. It essentially looks at requirements in an abstract way rather than contextualised as part of tasks to perform. The RESPECT process and similar methodologies, such as that by Beyer and Holtzblatt (1997), is centred upon the system end-user, the tasks they have to perform with the system, and the environment in which they work or operate.
The traditional requirements engineering approach defines what the user needs to do, not how it will be done. However the RESPECT process goes further and develops specifications of how the needs will be satisfied. It defines, for example, interactive procedures and organisational designs so that users become aware and are happy with the future implementation of the system. Normally needs analysis is like stamp collecting where ideas and wish list items are collected together. The RESPECT process is more comprehensive and structured, and provides a more complete view. Traditionally requirements are specified at different levels and may be unrelated or simply low level enhancements to the existing system. The RESPECT approach is based on representative tasks which are complete descriptions of what the user needs to do to achieve particular goals.
Thus an example task for a bank machine might be to "withdraw money". Thus the requirement would be for the user to be able to identify themselves, specify the amount they require, and to obtain the money. A more complete task description will perhaps describe the user, task and the possible environment at the time. For example: "a user in a wheelchair, wishes to withdraw £50 from the bank machine at night. However their current limit only allows £20 to be withdrawn". By considering all these aspects, the user requirements can be made more complete and take into account possible problems that may arise for the user.
A traditional requirements analysis will collect detailed partial tasks and functions that are needed to support those tasks. Corresponding to this within the RESPECT process, there are two phases: Phase 1- User context and early design which analyses current task processes, and Phase 2 - Prototype and user test which develops new processes and identifies new functions. Thus the RESPECT process and the traditional approach can complement each other. The traditional approach helps to ensure that all important functions of the system are recognised, while the representative task descriptions in the RESPECT process provide an integrated picture of the functions working together.
In the traditional "Specifications" phase of software engineering, the requirements are used to produce a description of the system that includes the details needed by the software designers and implementers. The customers or end-users can then sign off on this document, and the software team can begin to plan and design the actual system. However as users will typically not be experts at reading specification documents, they may have trouble imagining how the system will actually perform. Various alternatives to written specifications have been proposed, including prototypes and a more iterative approach to design, both of which form part of the RESPECT Framework. Thus a prototype of the system can be added to the requirements specification to illustrate how the new system will operate.
However the RESPECT Method also uses task scenarios (called 'usage cases') and documents how the user will interact with the new system in order to achieve the task goal. Thus customers will be able to understand this part of the specification. It will also force the specification writer to consider a complete task, which may catch problems that could otherwise be missed when functions are considered individually. Within Phase 3 - User requirements documentation, the RESPECT process will produce a user-oriented list of user requirements structured under different headings (e.g. functions and features, user support, and environmental requirements). These will provide a useful guide to the users to enable them to see what the future system will be like, and whether they wish to accept it or request changes.
From this point on, the strict Waterfall method and the RESPECT method may take different paths, although both work in parallel. As the design and implementation progresses, it is likely that changes will be needed to make sure that the system meets user needs. Based on the user-centred design principle of iterative design, several iterations of testing and redesign are likely to be required, which may involve jumping back through the phases of the waterfall method. At the same time, changes should also be made to RESPECT Phase 3 - User requirements documentation. This will allow users to refer to the current status of the requirements expressed in a form they will be able to understand. This will also allow them to maintain a good grasp of the development process as the system develops.
There are also parts of the RESPECT process that will be applied during the later stages of the Waterfall process. Firstly a test plan is described which will include usability test goals. By referring to this plan, users may take a more active part within the test process. They will thus be able to see at first hand whether the system is able to meet its usability goals. Also the process describes the requirements for user support and implementation. These will be specified to ease the process of user awareness and uptake of the new system. Again users will be able to refer to these descriptions in order to ensure that user support and implementation needs are being addressed properly.
The RESPECT project has produced a number of interrelated documents. This document, D5.3, forms the RESPECT Framework for analysing and specifying user requirements. The figure overleaf shows the relationship of this document to other RESPECT documents.
FIGURE 2. RELATIONSHIP BETWEEN RESPECT DOCUMENTS
Additional RESPECT documents supporting the user centred requirements engineering process are as follows:
This state of the art report on methods for user centred requirements elicitation and specification catalogues user-based requirements elicitation methods which have been shown to be of industrial relevance, and which can be adapted to the needs of the development of telematics applications.
This guide (Vossen and Maguire, 1998) assists in the process of translating the requirements generated by this Requirements Handbook into user interface specifications, taking account of different aspects of user needs. It includes a list of factors and possible requirements related to users, tasks and environments which should influence the user interface design. It also provides advice on user involvement in the design process.
This document (Heim et al, 1997) gives information on some of the basic requirements of young, old and disabled people and explains in detail how to design systems to take account of their needs. It also includes advice on carrying out methods for capturing user requirements and evaluating prototypes when applied to users with special needs.
Reference is made to these other documents at appropriate points in the requirements specification process (Part B of this document), indicated by the symbol:
Understanding user requirements is an integral part of information systems design and is critical to the success of projects such as those within the Telematics Applications Programme. However specifying these requirements is not so simple to achieve. How can a system be designed before the future situation is known? End-users may not appreciate the benefits that future technology can offer them. Once they understand the implications of a potential solution, their requirements may change. Similarly, the design team may find it difficult to integrate user opinions into the design process, and thus may concentrate only on the technical requirements of the system.
An important characteristic of the user requirements process is that user opinions of what they might want from a system will evolve. As a system concept develops, users will see new possibilities or potential problems and so the requirements will change.
A general approach to specifying user requirements needs to be flexible to meet different situations e.g. generic or custom system development, new systems or developments of existing systems. With these differences in mind, this framework document has been developed to offer a general structure from which relevant techniques can be selected and used as applicable.
This document offers an approach to specifying user requirements that is data driven. This means that the basis of the approach is to collect and generate user requirements under a series of section headings A range of different methods are suggested to capture the required data. Once captured, these data form the basis of the user requirements specification document.
The three main stages of the user requirements framework and their component sections can be represented as an iterative cycle, as shown in the figure overleaf. Each cycle contains an analysis of the context of use, the specification of user requirements, developing a design to meet those requirements and testing them against the requirements.
FIGURE 3. OVERVIEW OF RESPECT REQUIREMENTS AND DESIGN CYCLE
The main stages of this process are described below:
This consists of recording details the initial project requirement and design context.
Here the future users and stakeholders of the system are identified, and their roles in relation to the system are recorded.
Here user characteristics such as skills, physical attributes and personal details are recorded.
Here the technical characteristics of the current system (e.g. displays, keyboards, telephones) and possible future requirements are recorded.
The characteristics of the physical environment (e.g. lighting, sound and thermal conditions) and possible future requirements are recorded.
The characteristics of the social environment (e.g. organisational aims, staff and management structure, performance monitoring, group working) and possible future requirements are recorded.
User goals for the system are listed. Where there is a current system in place, user tasks to achieve each goal are identified.
User goals for the system are listed. Where there is a current system in place, user tasks to achieve each goal are identified.
Features of similar (possibly competitive) systems, which may need to be included or definitely excluded, are documented.
Design ideas and concepts for the new system are generated and represented in some way.
Expert reviews are carried out of the design ideas and concepts to assess their feasibility for use in the new system.
An assessment is made as to whether the design ideas and concepts form a sufficiently good basis for further development as a prototype. If so, then the process continues with phase 2.
To start the design process it is helpful to summarise general usability goals that the design is aiming to achieve. Also a checklist of guidelines may be considered to assist the process of user interface design.
Here constraints on the design process are listed.
Here a number of task scenarios which represent common or important task situations are listed. These are used to test the success of the prototype. Usability criteria are also established to help judge the success of the system in relation to the tasks. At least one scenario is required for each user goal.
For each scenario, a set of interaction steps are listed to demonstrate how the system should be used. A list of functions and features which support these steps are listed.
An interactive prototype is developed using software and/or hardware which users can interact with. This will then be used to test the system design.
The prototype is tested with users and observations recorded by evaluators. Also performance scores and subjective ratings are recorded which may be used as a basis for a user requirements test plan.
The tasks that the each user group will have to perform are reviewed to see how acceptable they are and components of a job.
The results of the prototype test and the task acceptability review are considered. If the prototype appears to be successful, the design can be used as a basis for the user requirements specification which is carried out in Phase 3.
In this Phase, the user requirements identified within Phases 1 and 2, are documented. A process of prioritisation is also carried out to ensure that the most important requirements are achieved. Progress on the achievement of each requirement is also monitored during the design process.
Here any general characteristics of the Design Concept are listed.
This section describes the intended organisational structure implied by the new system.
This section summaries the user goals and system related tasks that they will perform as part of the new system.
This section describes the user requirements for the future technical environment e.g. the software, hardware, other equipment, and other materials needed to perform the user tasks.
The main functions and features of the system are listed together with the user group each relates to.
This section describes the characteristics of the proposed user interface illustrating the structure and example screen layouts. A reference is also made to the system prototype and how to run it.
This section describes future user support requirements including on-line help, documentation, human support etc.
This section describes the user requirements for the future physical environment e.g. the lighting, sound, workstation layout etc.
This section describes the user requirements for the future social environment e.g. group working, assistance provided etc.
Here all relevant standards and interface styleguides that should be referred to during the design process are listed.
A plan for testing the system when it is implemented is developed. This is based on the previously identified task scenarios.
A description of the system phasing is required to show the migration path to the new system from the user's points of view.